Style-based Reenement for Software Architecture

A question that frequently arises for architectural design is \When can I implement a design in style S1 using a design in style S2?" In this paper I propose a technique for structur-ing a solution to this kind of problem using the idea of sub-styles. This technique leads to a two-step process in which rst, useful subsets of a family of architectures are identi-ed, and second, reenement rules speciic to these subsets are established. I will argue that this technique, in combination with an unconventional interpretation of reenement, clariies how engineers actually carry out architectural re-nement and provides a formal framework for establishing the correctness of those methods. 1 The importance of style-based reenement A key issue for architectural design is to understand when a system characterized in one style can be substituted for one described in another. That is, when can I use an instance of style S1 in place of a system already described in style S2? This problem arises in a number of contexts: Representing the internal structure of an architectural component (or connector): Often the elements of an architectural description are implemented internally by another, more detailed architecture. In some cases the boundary of one element serves to aggregate and encapsulate certain parts of a complex description (i.e., S1 = S2). In this case, simple name mappings between the internal representation and the external may suuce. But more generally, the internal representation may involve a change in architectural style. For example, I might have a component of a pipe-lter architecture that is internally constructed using componentry based on procedure-call. Recasting an architectural description in a new style: Often a system that is most naturally represented in one style must be implemented using the facilities that are best described in another style. In this case, a complete architectural description (not just individual elements) must be represented in a new way. For example, I might represent an event-based design in an object-oriented one, in order to pave the way for more direct implementation using an object-oriented language. Applying tools developed for one style to a system written in another one: Architectural analysis tools are often written for systems that t within a given style. For example, a timing analyzer may apply only to pipe-lter systems, while a transaction throughput analyzer might apply only to a certain class of repository-oriented systems. However, sometimes we have a system that is …